The Internet and the World Wide Web (WWW) provide intra-enterprise connectivity, inter-enterprise connectivity and application hosting on a larger scale than ever before. By exploiting the broadly available and deployed standards of the Internet and the WWW, system users and designers can leverage a single architecture to build client/server applications for internal use that can reach outside to customers, business partners and suppliers.
Each web site normally further provides a plurality of web pages to be served to the local computer systems upon request. Each local computer system may access the remote web sites with web browser software.
The WWW is a collection of servers on an IP (Internet Protocol) network, such as the Internet, an Intranet or an Extranet, that utilize the Hypertext Transfer Protocol (HTTP). Hereinafter, “Internet” will be used to refer to any IP network. HTTP is a known application protocol that provides users with access to files, which can be in different formats, such as text, graphics, images, sound, and video, using a standard page description language known as Hypertext Markup Language (HTML). Among a number of basic document formatting functions, HTML allows software developers to specify graphical pointers on displayed web pages, commonly referred to as “hyperlinks,” that point to other web pages resident on remote servers. Hyperlinks commonly are displayed as highlighted text or other graphical image on the web page. Selection of a hyperlink with a pointing device, such as a computer mouse, causes the local computer to download the HTML associated with the web page from a remote server. The browser then renders the HTML into the displayed web page.
Web pages accessed over the Internet, whether by a hyperlink, opening directly via an “open” button in the browser, or some other means, are commonly downloaded into the volatile cache of a local computer system. In a computer system, for example, the volatile cache is a high-speed buffer that temporarily stores web pages from accessed remote web sites. The volatile cache thus enables a user to quickly review web pages that were already downloaded, thereby eliminating the need to repeat the relatively slow process of traversing the Internet to access previously viewed web pages. This is called local caching.
On the server side, the first web servers were merely HTTP servers that resolved universal resource locators (URLs) by extracting literally from the URL the path to a file that contained the needed page, and transmitting the page back to the browser. Such a server was very simple; it could only be used to access static pages.
A “static” page is a page which, each time it is requested and served to a requester, has the same byte content. That is, it does not depend upon which requester is requesting the page, when the requester is requesting the page, etc.; the byte content of that page remains the same. By contrast, a “dynamic page” is a page which has byte content that may very well change depending upon the particular requestor, when the page is being requested, etc. This will be discussed further below. It is important that web pages be served as quickly as possible, both to reduce the response time to a single user, and to increase the number of users that can be served concurrently. To improve the response time, the Web server uses caches. Web server caches are used to store web page responses in a readily accessible memory location so that when the web page is requested by a user, a previously cached web page response can be retrieved from cache and served quickly to the user.
Caching web page responses by the web server works quite well for web page responses having static content, i.e., content that doesn't change frequently. An example of a static web page is one, at a company's web site, comprising a compilation of text and graphics objects describing that company's history.
In fact, classic web servers cache static pages quite effectively. Specifically, classic web servers serve web page responses, some of which are static, namely, responses comprising HTML from the file system. Each of the static responses has a last modified date associated with it that is maintained by the file system. The contents of the response and its associated last modified date are simply stored in the cache for possible future use by the web server. When a subsequent request is received by the server for that page, the server requests the latest modification date for that page from the file system and compares the latest modification date with the last modified date associated with the candidate cached response. If the latest modification date is the same as the last modified date associated with the candidate cached response, the candidate cached response is considered to be “fresh” and is served to the request (i.e., to the requesting user). If the latest modification date is later than the last modified date associated with the candidate cached response, the candidate cached response is considered “stale” and a “fresh” response is retrieved and built by the web server for serving to the requesting user. The fresh response, along with its associated last modified date, is cached to replace the stale response. This caching scheme saves the time and server processor cycles that otherwise would have been spent to build requested pages which otherwise could have been cached using this classic caching scheme.
However, newer web servers provide not only static web pages but also dynamic web pages, i.e., a page having byte content that may very well change depending upon the particular requester, when the page is being requested, etc. Examples of dynamic web pages are pages containing content from a number of different sources or pages having computed content. For example, a page may contain macros that compute content for the page, i.e., the page has “computable content”. These macros may change the page content each time the page is accessed. This makes it difficult to cache that page using the classic caching method described above. Macros or formulas are expressions that perform a function, such as determining field values, defining which documents appear in a view, or calculating values for a column.
Alternatively, the page may contain information from a number of different sources, and that information may or may not have associated last modified dates making it difficult, if not impossible, to cache using the classic caching method. For example, the page may comprise a composite of a number of “parts” including: other documents, designs from databases, content from databases, the present user's identity, the current time, the current environment, etc. Some of these parts are actual entities in the system, e.g., documents, databases, etc. Some parts though are “virtual” and are used to model the effects of the execution of macros or scripts, for example, the user's identity may be accessed via one of a number of macros for performing specialized. They can be used to format text strings, generate dates and times, format dates and times, evaluate conditional statements, calculate numeric values, calculate values in a list, convert text to numbers or numbers to text, or activate agents and actions. These various part types are computable parts and have correspondingly various types of attributes that can not be handled by the classic caching systems and methods.
Clearly, it is more difficult to use caching as a mechanism for improving user response time for pages with dynamic content. This problem for the server is twofold. First, after building a web page response, the server must determine whether the response that it is preparing to serve the requesting user is cacheable (i.e., determining its cacheability). Second, the server, upon receiving a request for a web page whose previous response has been cached, must determine whether the cached response is valid (i.e., determining its validity) and applicable (i.e., determining its applicability). For instance, web page responses containing macros that are time-dependent may not be cacheable at all. If a page includes a macro for providing the current time, then every access of the page is unique and the page cannot be cached in memory at all. Another example is where is a cached page is valid for serving to some users but not others. For instance, if the page includes a macro for the user's name, then the page can be cached for serving to that particular user, but not for serving to others. (HTML representing a document is specific to a user if macros are dependent on user name or user roles. Using this user data, some data may be made visible based on which user is requesting it.)
The term “Dynamic HTML” (DHTML) needs to be explained in the context of the embodiments of the present invention. “Dynamic” as used in DHTML is referring primarily to the effect that the code has on the web page appearance at the browser. For instance, the dynamic HTML may comprise scripts that run on the browser to change the appearance of the web page such as by displaying a button that, if pushed, displays additional text or graphics. The key distinction is that “dynamic” in the DHTML sense refers to the browser, not the server. From the server's point of view, a DHTML page may still be “static” in that the byte content may be the same each time the page is requested, so for the purposes of this invention, a DHTML page may be “static” or “dynamic” in the sense of the invention. The content is not dependent on any thing, e.g., the properties of the request, such as the identity of the particular user, the time of day that the request is made, etc. “Dynamic” content, as used in the embodiments of the present invention, refers to content that has such dependencies. Thus, “dynamic” in the DHTML sense is not related to “dynamic” in the sense of the embodiments of the present invention.
The problems may be further expressed as that of not knowing which dynamic content such as that found in JSP (Java server page) and ASP (active server page) technology need to be cached and then how to cache effectively. Further when implementing a manual cache configuration incorrect assumptions may cause system performance degradation. This problem arises when developers construct dynamic pages but do not cache them appropriately; which may then lead to poor system performance. Additional decisions based on the various dynamic properties of the page are required regarding whether to not cache a particular dynamic page at all or to cache it as a page fragment or a composite page (including sub-fragments). The drawback of these solutions is the need for significant knowledge of the dynamic content design and the system's dynamic content caching infrastructure.
As can be readily seen, using caching as a means for increasing server performance for responses which have dynamic content has a number of complications and difficulties which have not been overcome by prior systems. As such, HTML representing responses having dynamic content has not been cached in the past. Accordingly, an embodiment to cache content that can include dynamic content without suffering from the drawbacks discussed above is needed. An additional solution is required to make the caching process simpler such that developers can easily determine which dynamic content needs to be cached and how the content should be cached.